Repository navigation
Conversation
6c081b4 to
cbe82c2
Compare
|
I bumped CI timeout to 90 minutes since the POCL backend of KA 0.10 increases testsuite runtime and the macOS runners with only 1 job were right on the edge (either side) I cancelled the latest Buildkite run since the GHA timeout increase was the only change since the last successful run. |
7dd9c6b to
0266f3c
Compare
784d123 to
764ad56
Compare
|
Not sure this is the best approach but Claude redesigned the JLArrays storage to support bits union. |
|
Did you rebase out my changes? Looking at your force push, you went from https://github.com/JuliaGPU/GPUArrays.jl/commits/784d123d40e549406b292c57a61bfb1fe6c1d5ed/ to https://github.com/JuliaGPU/GPUArrays.jl/commits/764ad56eba1db4cf6a617083edf2ccaaea145ede/, which lacks the result of my rework last week (as reflected by the edited top post). |
|
I think I might have I missed the rework. The commit is probably still on my laptop I’ll revert my changes in a few hours. |
|
No worries. Maybe just have your Claude session incorporate those changes? It cleaned-up the implementation a bit, too. |
a4f65cf to
52517b8
Compare
|
Ok I had Claude recover your changes, rebase, and then reincorporate the storage backing I'm unsure about. Tests should pass once KA cpu backend has bitsunion support |
maleadt
changed the title
|
I reworked this together with #827, now that KernelAbstractions 0.10.5 is out (with JuliaGPU/KernelAbstractions.jl#944). I dropped the On #827: I kept the KernelInterface port and the padding removal (2048² Float32 matmul on an RTX 5080: 5.1 ms → 3.5 ms; the PTX only uses vector shared loads without the padding). I dropped the |
|
Nice! I didn't like that workaround at all. Regarding #827, once that's merged and we have a version of |
With KernelAbstractions 0.10, JLArray kernels run on its POCL back-end. Drop the KA 0.9 code paths, including JLDeviceArray, and convert JLArrays to POCL device arrays. Leave `Ref`s to POCL's conversion after converting their contents, so that `Ref`s of types, as passed by `convert.(T, A)`, are handled too. POCL's SPIR-V back-end cannot lower 128-bit integers, so stop testing Int128 with JLArrays.
Make JLBackend a KernelInterface back-end, like the GPU back-ends that moved to KernelAbstractions 0.10: it converts arguments to POCL's and forwards compilation, launches and device queries to the POCL back-end. Run the KernelAbstractions and KernelInterface testsuites on it, skipping the dense-to-sparse test, which JLArrays don't support, and the tests that only exercise KernelAbstractions' own CPU back-end. KA 0.10's CPU back-end has no static scheduling anymore, so this removes the `static` option of JLBackend.
KernelAbstractions narrows `@index` computations to Int32 on every back-end but POCL, because on POCL the narrowing keeps LLVM from vectorizing the loops over work-items. JLArray kernels run on POCL, but JLBackend isn't a POCLBackend, so they got Int32 indices. Using Int speeds up a 2048x2048 element-wise kernel by about 7%.
A JLArray was converted to a POCL device array by wrapping its memory in an Array and adapting that with a fresh KernelAdaptor, allocating both on every conversion, which happens several times per argument per launch. Construct the device array from the JLArray's pointer instead. This reduces the allocations of `c .= a .+ b` from 1344 to 480 bytes. This also converts arrays of isbits unions, whose storage an `Array` can't wrap: POCL's device arrays find their selector bytes `maxsize` bytes past the data, so point that at the JLArray's own.
JLArrays reduced, sorted, scanned and searched with Base on an `Array` wrapping its storage, because AcceleratedKernels' kernels did not run on its KA 0.9 back-end. On KA 0.10 they run through POCL like any other kernel, so JLArrays now takes the same code paths as the GPU back-ends instead of bypassing them. This also makes these operations work on arrays of isbits unions: an `Array` can't wrap their storage, whose selector bytes follow the data, while POCL arrays can.
The port to KernelAbstractions 0.10 is breaking: `JLBackend(; static)` and `JLDeviceArray` are gone.
The KernelAbstractions and KernelInterface testsuites, and kernels for every reduction, sort and scan, make JLArrays' tests slower. The macOS runners, which run one test at a time, were already close to the 60-minute limit.
4de3fad to
d52a3e6
Compare
JLArrays, the CPU reference back-end used to test GPUArrays and downstream packages without a GPU, still targets KernelAbstractions 0.9. The vendor back-ends (CUDA, AMDGPU, Metal, oneAPI, OpenCL) have moved to KernelAbstractions 0.10, which builds on KernelInterface, so a test environment using JLArrays can't move along with them.
This ports JLArrays to KernelAbstractions 0.10 and drops 0.9.
JLBackendbecomes a KernelInterface back-end in the same shape as the vendor ports: it converts arguments to POCL device arrays and forwards compilation, launches and device queries to KernelAbstractions' POCL back-end, which is what runs KA 0.10 kernels on the CPU. The KernelAbstractions and KernelInterface testsuites now run on JLArrays, skipping the same POCL-only tests the vendor back-ends skip.JLArrays used to reduce, sort, scan and search with Base on an
Arraywrapping its storage, because AcceleratedKernels' kernels did not run on its KA 0.9 back-end. They do now, so JLArrays takes the same AcceleratedKernels code paths as the GPU back-ends instead of bypassing them. This is also what makes those operations work on arrays of isbits unions, which the testsuite requires since #835: anArraycan't wrap their storage, while POCL's device arrays (as of KernelAbstractions 0.10.5) read the selector bytes JLArrays keeps after the data. The cost is test time, as every operation now compiles a kernel: the reduction, sorting and scan testsets take about twice as long.Along the way:
convert.(T, ::JLArray)failed to compile, because JLArrays wrappedRefs before POCL could recognize aRefof a type. JLArrays now converts only what theRefholds.Intlike POCL's own, instead of theInt32KernelAbstractions uses on GPUs, which keeps LLVM from vectorizing over work-items (~7% on a 2048×2048 element-wise kernel).c .= a .+ bgoes from 1344 to 480 bytes).This is breaking, hence JLArrays 0.5:
JLBackend(; static)is gone, since KA 0.10's CPU back-end has no static scheduling, and so isJLDeviceArray(JLArrays are POCLCLDeviceArrays in kernels). POCL's SPIR-V back-end cannot lower 128-bit integers, soInt128is no longer tested with JLArrays.The macOS runners, which run tests one at a time, were already close to the 60-minute job limit, so the limit is raised to 90 minutes.